[Previous] [Next] [Index] [Thread]

Re: PGP and WWW (was "Securing information transports")

On Fri, 13 Oct 1995, Adam Cain wrote:

> We're working on revising the PGP support for web browsers and servers,
> addressing the aforementioned deficiencies and hopefully bringing it to
> a usable state.  The current, experimental approach involves using a
> CCI app (Common Client Interface application) front end to PGP which
> communicates with the browser and handles PGP-related user interface tasks.
> This alleviates the need for crypto-specific hooks in the browser, and makes
> it easier to use with any browser sporting a compatible, general-purpose
> interface like CCI.  Naturally, there are numerous pro's and con's associated
> with this scheme.

I work for CSIRO which is dispersed across Australia.  We use the Web to 
make "CSIRO only" information available to our staff, and largely running 
the NCSA HTTP, we use the access.conf file to restrict access to 
directories based on host name of ".csiro.au".  We are aware of how DNS 
spoofing makes this circumventable, and how it inconveniences CSIRO staff 
working in other organizations such as Universities, which is quite common.

Hence, we are experimenting with using PGP as a means of authentication. 
We chose PGP because it is free for our use, the source code is available,
it is widely used and understood (for a public key system anyway), and we
can use it for authentication to systems (such as telnet and CGI scripts),
authentication of email and for encryption. 

However, our users run a variety of browsers on a variety of hardware, 
and using CCI or the Netscape equivalent didnt seem like a good approach, 
unleast until these API's become more "common" (maybe java is the way out 
of this, plus platform independence).  So, we are using the "helper" 
application interface, whereby a message with a specific MIME type is 
used to send a challenge to be signed by the "popped-up" helper app, 
which is a shell over the PGP command line interface.  The shell sends 
the message back to the machine sending the challenge on a seperate (non 
HTTP) WWW connection, which authenticates the user and binds the user to 
that IP addr for an application-specific period of time.

For browsing WWW pages which are thought "very sensitive", this time is 
short.  For general internal pages (such as telephone # which we are not 
allowed to publish to non-CSIRO staff due to our privacy legislation), 
the time is longer.  Because their is no real TCP session, we are vulnerable
to another user "stealing" the IP addr of an authenticated user.

Pages can also be encrypted with the public key of the current bound user 
- in this case the helper app pops up, prompts user for their passphrase, 
decrypts the data to a disk file an initiates an "open local file" 
operation on the browser (keystrokes used must be customized for each 
browser).

This required changes to the httpd source to parse a new "allow from" syntax
in access.conf and process it/issue the challenge/check the response.  It
is not in a form which we could reasonably share, unfortunately.

We also have some CGI scripts which explictly challenge with something we 
want the user to sign (the equivalent of a purchase order, say) and process 
the response.

We also handle the PGP key generation and upload of the public key to a
central server using Web forms - user requests a key which emails the
helpdesk who contact the user "out of band" to establish their identity
and give them an upload password which they must supply when uploading
their public key.  The user is "wakled thru" the key generation process
with web pages. 

The Windows client works, and most of the functionality has been ported 
to X, and the Mac port is almost ready.

Obviously, SSL is a serious alternative to this, and so probably is
S-HTTP, but we are in a dilema as we cannot specify what clients our users
use.  Also, PGP is actually very effective, the the helper app approach
allows a "loose coupling" which although not providing an integrated
solution, provides a robust approach across clients and platforms. 

What we have done so far is just a first step - we needed to do something.
I think we are keen to continue with PGP, but in the medium term, we'd 
like to see crypto/authentication "hooks" in the servers and clients we use 
- again, maybe java is the way to go.

Kent Fitch                           Ph: +61 6 276 6711
ITSB   CSIRO  Canberra  Australia    kent.fitch@its.csiro.au
"Unusual travel arrangements are dancing lessons from the gods."
				- Kurt Vonnegut
References: